I have made here a repository which generates random user data and creates a pdf with the data.
Here are both pdf's so you can see the difference.
Before.pdf
After.pdf

I have noticed that the width of the columns differs on the different sheets. This is due to the "ShowOnce" element. On page 2, the sizes of the cells from page 1 are not calculated because they are already rendered.
I don't know exactly what the element is for. But wouldn't it theoretically be enough to calculate the width of the columns once per table instead of doing it once for each page? Or can the width of the columns on the individual sheets in the same table be different?

I don't know exactly what the element is for. But wouldn't it theoretically be enough to calculate the width of the columns once per table instead of doing it once for each page? Or can the width of the columns on the individual sheets in the same table be different?

It is expected that elements may have different sizes across pages. ShowOnce is only one potential root cause.

I understand the desired behavior is that shrank/grown columns should have identical widths across all pages. In such a case, determining all widths will be genuinely challenging, as changing width also potentially changes displayed content, creating a feedback loop.

Personally, I don't care if the columns are the same width on each sheet. For me it fits as it is after the PR.
I tested it locally without ShowOnce and noticed that the width was the same on all pages. Of course, if the elements can have different widths on different pages (although I don't understand how this is possible), it can stay that way.

I have updated the pr to fix the different columns width per page.
Now, after the first time UpdateColumnsWidth is called the width of all columns are stored.
If the method is called again the stored values are used. I hope this is okay so...

Hi @MarcinZiabek,

I hope you're doing well.

I wanted to kindly remind you about the pull request. I have made some adjustments and have been waiting for your feedback. If you could find some time to review the changes, I would greatly appreciate it.

Thank you very much for your help and time.

Best regards

@Hummel37 Let me thank you once again for exploring this feature and submitting a pull request. I apologize for the delayed response and action. Ensuring the quality of the 2024.3.X release has been my top priority recently. Although things are slowly stabilizing, it still demands a surprising amount of time.

At this moment, I plan to release the final 2024.3.X version soon, and then focus on the upcoming major release.

Considering that the Table element is one of the most commonly used components, I need to be very careful when introducing changes:

• Assess performance, time, and memory complexity – some users generate tables with hundreds of thousands of cells.
• Assess potential scalability and maintenance issues – as QuestPDF is a library, once a change is made, it becomes a commitment that cannot be easily reversed or adjusted later. Therefore, every change needs to align with the long-term plan.

That being said, I am committed to revisiting every open pull request and doing my best to implement them.

I am currently preparing a roadmap for the upcoming months. I am excited to include this enhancement, likely for the August release. I will share more details next week.

Thank you for your feedback, support and patience 😄